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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Network sharing is a way for operators to share the heavy deployment costs for mobile networks, especially in the roll- 
out phase. In the current mobile telephony marketplace, functionality that enables various forms of network sharing is 
becoming more and more important. These aspects have not really been addressed before Release 6 in 3GPP UTRAN 
based access networks, before Release 8 in 3GPP E-UTRAN based access networks and before Release 10 in 3GPP 
GERAN based access networks, although there has been functionality that supports a very basic type of network 
sharing since the Release 5 versions of the 3GPP specifications. 

To cope with 3GPP pre-Release 6 UTRAN UEs and with non supporting 3GPP GERAN UEs, this specification 
describes extra functionality for MSCs, SGSNs, BSCs and RNCs in order to provide network sharing functionality to 
"non-supporting UEs". 

In this Release of the specifications, all UTRAN and E-UTRAN capable UEs are required to support the UTRAN and 
E-UTRAN network sharing requirements. Hence the E-UTRAN and MMEs (which were introduced in 3GPP 
Release 8) do not need functionality to handle "non-supporting UEs". 

Scenarios and user requirements are described in TR 22.951 [1], while the current document presents the stage 2 details 
and descriptions of how these requirements are supported in a 3GPP GERAN, UTRAN and/or E-UTRAN based 
network. 
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Scope 



The present document covers the details of Network Sharing for GERAN, UTRAN and E-UTRAN. It shows how 
several core network operators can share one radio access network and details the impacts on the network architecture. 
All UEs shall comply with existing requirements, among them PLMN selection and system information reception. The 
present document also defines requirements for network-sharing supporting UEs. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definition below apply. Terms and definitions not 
defined below can be found in TR 21.905 [2]. 

Conventional network: A PLMN consisting of radio access network and core network, by which only one serving 
operator provides services to its subscriber. Subscribers of other operators may receive services by national or 
international roaming. 

Common PLMN: The PLMN-id indicated in the system broadcast information as defined for conventional networks, 
which non-supporting UEs understand as the serving operator. 

Core network operator: An operator that provides services to subscribers as one of multiple serving operators that 
share at least a radio access network. Each core network operator may provide services to subscriber of other operators 
by national or international roaming. 

Gateway Core Network: A network sharing configuration in which parts of the core network (MSCs/SGSNs/MMEs) 
are also shared. 

Multi-Operator Core Network: A network-sharing configuration in which only the RAN is shared. 

Non-supporting UE: A UE that does not support network sharing in the sense that it ignores the additional broadcast 
system information that is specific for network sharing for 3GPP UTRAN and GERAN. In other specifications, the term 
"network sharing non-supporting UE" may be used. 

Supporting UE: A UE that supports network sharing in the sense that it is able to select a core network operator as the 
serving operator within a shared network. In other specifications, the term "network sharing supporting UE" may be 
used. 

Anchor PLMN: With regard to SRVCC from CS to PS, this Anchor PLMN points to the PS domain operator in which 
the voice media is anchored in Access Transfer Gateway as part of the SRVCC procedure. 
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3.2 



Void 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [2] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [2]. 

BSC Base Station Controller 

CN Core Network 

E-UTRAN Evolved Universal Terrestrial Radio Access Network 

eNodeB E-UTRAN NodeB 

gsmSCF GSM Service Control Function 

GERAN GSM/EDGE Radio Access Network 

GUTI Globally Unique Temporary Identity 

GWCN Gateway Core Network 

HLR Home Location Register 

HSS Home Subscriber Server 

MCC Mobile Country Code 

MME Mobility Management Entity 

MNC Mobile Network Code 

MOCN Multi-Operator Core Network 

MSC Mobile Switching Centre 

NITZ Network Identity and Time Zone 

PLMN PubUc Land Mobile Network 

RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

TMSI Temporary Mobile Subscriber Identity 

UE User Equipment 

UTRAN Universal Terrestrial Radio Access Network 

VLR Visitor Location Register 



General Description 



4.1 



Overview 



A network sharing architecture shall allow different core network operators to connect to a shared radio access network. 
The operators do not only share the radio network elements, but may also share the radio resources themselves. In 
addition to this shared radio access network the operators may or may not have additional dedicated radio access 
networks, like for example, 2G radio access networks. There are two identified architectures to be supported by network 
sharing. They are shown in the figures below. 

In both architectures, the radio access network is shared. Figure 1 below shows reference architecture for network 
sharing in which also MSCs and SGSNs are shared. This configuration will be referred to as a Gateway Core Network 
(GWCN) configuration. 
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Figure 1 : A Gateway Core Network (GWCN) configuration for networit sharing. 
Besides shared radio access networit nodes, the core networit operators also 

share core network nodes 

Figure 2 below shows the reference architecture for network sharing in which only the radio access network is shared, 
the Multi-Operator Core Network (MOCN) configuration. 




RNC 



'\ Radio Access Network / 
'"■-.... Operator X -•■■ 

Figure 2: A Multi-Operator Core Network (MOCN) in which multiple CN nodes are 
connected to the same RNC and the CN nodes are operated by different operators 

The UE behaviour in both of these configurations shall be the same. No information concerning the configuration of a 
shared network shall be indicated to the UE. 

For the Evolved Packet System, only the PS domain of the above figures is relevant. For E-UTRAN access Figures 1 
and 2 both apply but with the MME replacing the SGSN, the eNodeB replacing the RNC, and the S 1 reference point 
replacing the lu interface. 

For GERAN access, both GWCN and MOCN are applicable but with the BSC replacing the RNC and the A/Gb- 
Interfaces replacing the lu interface. 

4.2 Core Network Operator ancd Network Selection 

Network sharing is an agreement between operators and shall be transparent to the user. This implies that a supporting 
UE needs to be able to discriminate between core network operators available in a shared radio access network and that 
these operators can be handled in the same way as operators in non-shared networks. 



4.2.1 Core network operator identity 

A core network operator is identified by a PLMN-id (MCCh-MNC). 
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4.2.2 Broadcast system information for networl< sinaring 

Each cell in shared radio access network shall in the broadcast system information include information concerning 
available core network operators in the shared network. The available core network operators shall be the same for all 
cells of a Location Area in a shared UTRAN or GERAN network. The available core network operators shall be the 
same for all cells of a Tracking Area in a shared E-UTRAN network. A supporting UE decodes the broadcast system 
information and takes the information concerning available core network operators into account in network and cell (re- 
)selection procedures. Broadcast system information is specified in TS 44.018 [16] for GERAN, TS 25.331 [3] for 
UTRAN and TS 36.331 [11] for E-UTRAN. 

4.2.3 Networl< selection in a sinared network 

4.2.3.1 Behaviour of supporting UEs (GERAN, UTRAN and E-UTRAN) 

In some sharing scenarios, the sharing operators require the UTRAN/GERAN to broadcast, to non-supporting UEs, a 
PLMN ID that does not identify any of the sharing core network operators. In this case, it is necessary that a supporting 
UE does not select this "common PLMN ID". 

In other sharing scenarios, the sharing operators may want the PLMN broadcast to non-supporting UEs to be selectable 
by supporting UEs. 

A supporting UE decodes the broadcast system information to determine available core network operators in the shared 
network. The UE regards both the core network operators indicated in the broadcast system information and 
conventional networks as individual networks. The core network operators together with all conventional networks are 
candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23.122 [4]. 

In GERAN and UTRAN, non-supporting UEs use the broadcast "common PLMN-id" in their PLMN (re)selection 
processes. 

In UTRAN, supporting UEs shall use the PLMN-ids that are broadcast in the Multiple PLMN ID List information 
element in their PLMN (re)selection processes. UTRAN AS signalling permits the Multiple PLMN ID List to indicate 
to supporting UEs whether to include or exclude the MCCh-MNC of the "common PLMN-id" in their network 
(re)selection processes. 

For supporting UEs, GERAN provides equivalent functionality to UTRAN. 

For E-UTRAN, the UE uses all of the broadcast PLMN-ids in its PLMN (re)selection processes. 

4.2.3.2 Behaviour of non-supporting UEs (GERAN, UTRAN) 

Non-supporting UEs ignore the broadcast system information that is relevant for network sharing. The common PLMN 
together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be 
performed by the UE as specified in TS 23.122 [4]. 

It is recommended for the network and the UE to support the Network Identity part of the Network Identity and Time 
Zone (NITZ) feature (see TS 22.042 [18]) for providing the UE with the name of the serving PLMN operator. 

4.2.4 Assignment of core network operator and core network node 

When a UE performs an initial access to a shared network, one of available CN operators shall be selected to serve the 
UE. For non-supporting UEs, the shared network selects an operator from the available CN operators. For supporting 
UEs, the selection of core network operator by the UE shall be respected by the network. Supporting UEs inform the 
BSC/RNC/eNodeB of the network identity of the chosen core network operator. 

In a UTRAN GWCN configuration, the RNC relays the chosen network identity to the shared core network node (in 
UTRAN MOCN, the RNC indicates that the UE is a "supporting UE" by relaying the chosen network identity to the 
core network node). To permit GWCN operation, in E-UTRAN, the eNodeB always relays the chosen network identity 
to the shared MME. In a GERAN GWCN configuration, the BSC relays the chosen network identity to the core 
network node (in GERAN MOCN, the BSC indicates that the UE is a "supporting UE" by relaying the chosen network 
identity to the core network node). 
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In a MOCN configuration, the RAN routes the UE's initial access to the shared network to one of the available CN 
nodes. Supporting UEs shall inform the RAN of the chosen core network operator so that the RAN can route correctly. 
For non-supporting UEs the shared network selects an operator from the available CN operators. A redirection to 
another CN operator may be required for non-supporting UEs until an operator is found that can serve the UE. 
Redirection is described in clause 7.1.4. 

After initial access to the shared network the UE does not change to another available CN operator as long as the 
selected CN operator is available to serve the UE's location. Only the network selection procedures specified in 
TS 23. 122 [4] may cause a reselection of another available CN operator. Also the network does not move the UE to 
another available CN operator, e.g. by handover, as long as the selected CN operator is available to serve the UE's 
location. Furthermore the UE does not change to another CN node as long as the selected CN node is available to serve 
the UE's location. 

In GERAN and UTRAN, when the network signals location/routing area identities to supporting UEs, e.g. in location 
updating accept messages, these identities shall contain the chosen core network operator identity. For non-supporting 
UEs, they shall contain the common PLMN. The UE stores the received LAI/RAI on the SIM/USIM, as already 
specified in TS 24.008 [7]. 

In E-UTRAN, the chosen core network operator identity is included in the GUTI in e.g. the Attach Accept message. 
The UE shall store the received GUTI on the USIM according to the rules specified in TS 24.301 [12]. 

4.2.5 PS and CS domain registration coordination in UTRAN and GERAN 

In conventional networks, the same CN operator always serves the UE in CS and PS domains. In a shared network, 
supporting UEs shall behave as UEs in conventional networks with respect to registration with CS and PS domains and 
always register with the same operator for the CS and PS domains. CS/PS coordination should be performed at 
registration when a redirect attempt flag is included in A/Gb/Iu messages carrying the NAS registration message (see 
TS 48.008 [25], TS 48.018 [24], and TS 25.413 [13]). The term registration includes attach, and LA and RA updates. 

When multiple PLMNs are available and SRVCC from UTRAN/GERAN CS domain to E-UTRAN/HSPA PS is 
deployed, the source BSC/RNC determines a core network operator to be used in the target network based on current 
PLMN in use. Anchor PLMN provided by PS core network, or other information present in the BSC/RNC. The source 
BSC/RNC shall at handover indicate the selected core network operator to the source core network node in the 
handover required message. The anchor MSC Server shall forward the selected core network operator chosen by the 
source BSC/RNC to the target MME/SGSN. 

4.2.5a PS and CS domain registration coordination in E-UTRAN 

When multiple core network operators share the E-UTRAN using a GWCN configuration, separate MSCs may still be 
used for the CS Fall Back functionality. In this case the MME uses the 'selected network' information received from the 
E-UTRAN to select an MSC from the already selected operator. 

When multiple PLMNs are available for CS domain, the MME selects the MSC for CS Fallback functionality based on 
the 'selected network' information received from the E-UTRAN, current TAI, old LAI provided by the UE and operator 
selection policies as specified in TS 23.272 [15]. In this case, the selected PLMN-id for CS domain may be different to 
the PLMN-id for EPS domain. If the selected MSC is shared network configured, the MME selects the CS domain 
operator as specified in TS 23.272 [15]. If the UE is a GERAN network-sharing non-supporting UE and the preferred 
RAT of the selected CS network is GERAN with GWCN configuration, the MME sends the 'selected CS domain 
operator' to the VLR. If the MSC is GWCN configured, the MSC determines the CN operator, either (i) the selection is 
based on the 'selected CS domain operator' sent by the MME, or (ii) the selection is based on the local policy (e.g. uses 
a fixed spHt of IMSI ranges or IMSI hash). 

When multiple PLMNs are available for CS domain and SRVCC from E-UTRAN PS to UTRAN/GERAN CS domain 
is deployed, the MME sends the Handover Restriction List (see TS 23.401 [9]) to eNB including the currently serving 
PLMN and equivalent PLMNs together with information about which PLMNs are preferred for SRVCC. The eNB 
selects target PLMN for SRVCC from the list based on HRL and local policy and constructs the Neighbour Cell list 
(NCL) based on this knowledge of the target PLMN. The selected target core network PLMN should, if possible, be the 
same as the one in use. 

4.2.5.1 PS and CS domain registration coordination in MOCN 

In MOCN configuration the following alternatives are applicable: 
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At combined registration there are two methods: 

a) Operator centric: When a SGSN node receives a registration from a subscriber with a non-supporting UE 
having a P-TMSI not belonging to the shared and non-shared networks of the operator, it determines a 
serving CN operator based on local SGSN policy (see clause 5.4). The UE may then have to be redirected to 
a SGSN of another core network operator. The PS domain NRIs (and MMECs) are coordinated as in 
clause A. 1 . At mobility this means that the source network selects operator in target network (including Cell 
reselection, Handover, CS fallback). The SGSN may indicate over Gs interface the selected CN operator that 
serves the subscriber. 

b) Pool centric: When a SGSN node receives a registration from a subscriber with a non-supporting UE having 
a P-TMSI not belonging to the pool, and no IMSI is provided by RNC/BSC, it determines a serving CN 
operator based on local SGSN policy (see clause 5.4). The UE may then have to be redirected to a SGSN of 
another core network operator. At mobility to a new pool this means that the target network selects operator 
in a domain when the UE becomes idle in that domain (a selection of target network operator done by source 
network at Handover or CS fallback shall be respected, until the UE enters idle mode at which pool centric 
CS/PS coordination may change this selection). The SGSN may indicate over Gs interface the selected CN 
operator that serves the subscriber. 

Alternatively, in networks not using Gs the RNC/BSC may for non-supporting UE's coordinate that the CS and 
PS registrations for a given subscriber are always sent to the same CN operator. In that case RNC/BSC based 
coordination of PS and CS domain registration is configured in CN nodes and RNC/BSC. There are two methods 
for CS/PS coordination: 

a) Operator centric: When a CN node receives a registration from a subscriber with a non-supporting UE having 
a P-TMSI/TMSI not belonging to the shared and non-shared networks of the operator , it returns a Reroute 
Command message to the RNC/BSC (according to clause 7.1.4 "Non-supporting UEs in a MOCN 
configuration") with an indication that it is for coordination purposes. The PS and CS domain NRIs (and 
MMECs) are coordinated as in clause A. 1 . At mobility this means that the source network selects operator in 
target network (including Cell reselection. Handover, CS fallback). 

b) Pool centric: When a CN node receives a registration from a subscriber with a non-supporting UE having a 
P-TMSI/TMSI not belonging to the pool, and no IMSI is provided by RNC/BSC, it returns a Reroute 
Command message to the RNC/BSC (according to clause 7.1.4 "Non-supporting UEs in a MOCN 
configuration") with an indication that it is for coordination purposes. At mobility to a new pool this means 
that the target network selects operator in a domain when the UE becomes idle in that domain (a selection of 
target network operator done by source network at Handover or CS fallback shall be respected, until the UE 
enters idle mode at which pool centric CS/PS coordination may change this selection). 

The coordination is done in the RNC/BSC (without memorising IMSI information for IDLE mode UEs), e.g. uses a 
fixed split of IMSI ranges or IMSI hash table between operators. The coordination may result in that the registration is 
sent back to the same CN node or CN operator again. 

NOTE 1 : MOCN Pool centric CS/PS coordination based on, for example, a fixed split of IMSI ranges or an IMSI 
hash table between operators may lead to a change of operator when source network is, for example, a 
dedicated network. Such CS/PS coordination can only coordinate CS and PS operator if the source 
network performs handover and CS fallback to the operator defined by the fixed split of IMSI ranges or 
IMSI hash table in the target shared network. 

NOTE 2: A network in which Gs is in use should be configured not to use RNC/BSC coordination when a UE has 
initiated combined registration. 

NOTE 3: For the operator centric approach in MOCN: 

the limited NRI space may restrict the number of nodes that can be used by individual sharing 
partners, particularly in large networks with several operators. 

interactions between NRI-based routing and load-balancing functionality may lead to a skewed load 
of nodes within pools of the shared network, for example, for UEs entering the shared network from 
areas that are not NRI coordinated with the shared network. 

4.2.5.2 PS and CS domain registration coordination in GWCN 

In GWCN the following alternatives are applicable: 
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For combined registration of non-supporting UEs, either both the SGSN and the MSC are configured by same 
local policy for selecting CN operator, or SGSN is configured with local policy selecting CN operator and 
indicates over Gs interface the selected CN operator that serves the subscriber. At combined registration there 
are two methods: 

a) Operator centric: When a SGSN node receives a registration from a subscriber with a non-supporting UE 
having a P-TMSI not belonging to the shared and non-shared networks of the operator, it determines a 
serving CN operator based on local SGSN policy (see clause 5.4). SGSN indicates over Gs interface the 
selected CN operator that serves the subscriber. The PS domain NRIs (and MMECs) are coordinated as in 
clause A. 3. At mobility this means that the source network selects operator in target network (including Cell 
reselection. Handover, CS fallback). 

b) Pool centric: When a SGSN node receives a registration from a subscriber with a no n- supporting UE having 
a P-TMSI not belonging to the pool, and no IMSI is provided by RNC/BSC, it determines a serving CN 
operator based on local policy (see clause 5.3 and 5.4). The SGSN may indicate over Gs interface the 
selected CN operator that serves the subscriber. Alternatively, by the same policy in MSC and SGSN the 
non-supporting UE becomes CS/PS coordinated. At mobility to a new pool this means that the target network 
selects operator (including Cell reselection. Handover, CS fallback). 

Alternatively, in networks not using Gs the SGSN and the MSC may be configured by same local policy for 
selecting CN operator. There are two methods for CS/PS coordination: 

a) Operator centric: When a CN node receives a registration from a subscriber with a non-supporting UE having 
a P-TMSI/TMSI not belonging to the shared and non-shared networks of the operator, it determines a serving 
CN operator based on local policy (see clause 5.3 and 5.4). By the same policy in MSC and SGSN the non- 
supporting UE becomes CS/PS coordinated. The PS and CS domain NRIs (and MMECs) are coordinated as 
in clause A. 3. At mobility this means that the source network selects operator in target network (including 
Cell reflection. Handover, CS fallback). 

b) Pool centric: When a CN node receives a registration from a subscriber with a non-supporting UE having a 
P-TMSI/TMSI not belonging to the pool, and no IMSI is provided by RNC/BSC, it determines a serving CN 
operator based on local policy (see clause 5.3 and 5.4). By the same policy in MSC and SGSN the non- 
supporting UE becomes CS/PS coordinated. At mobility to a new pool this means that the target network 
selects operator (including Cell reselection. Handover, CS fallback). 

NOTE: For the operator centric approach in GWCN: 

the limited NRI space may restrict the number of nodes that can be used by individual sharing 
partners, particularly in large networks with several operators. 

interactions between NRI-based routing and load-balancing functionality may lead to a skewed load 
of nodes within pools of the shared network, for example, for UEs entering the shared network from 
areas that are not NRI coordinated with the shared network. 

4.2.6 Attach/detach handling 

To attach to the same core network operator from which it detached, a UE uses information stored in the UE (e.g. on the 
SIM/USIM) when the UE was detached. For a supporting UE in a shared network, the stored information indicates the 
core network operator it detached from (as specified in clause 4.2.4). This information enables a supporting UE to 
attach to the same core network operator from which it detached. For non-supporting UEs in a shared network, the 
stored information indicates the common PLMN. 

4.3 Network Name Display for Supporting UEs 

A supporting UE shows the name of the PLMN -id it has registered with. In case of a shared network, it is the PLMN -id 
of the chosen core network operator. The name stored in the UE for the PLMN -id is displayed except when the network 
indicates to the UE a name to be displayed, as already specified for non-supporting UEs. 



£75/ 



3GPP TS 23.251 version 1 1 .4.0 Release 11 14 ETSI TS 1 23 251 V1 1 .4.0 (201 3-01 ) 



4.4 HPLMN Support 



The use of a shared VLR/SGSN/MME shall not result in service restrictions, e.g. roaming restrictions. Since the HSS 
and gsmSCF derives whether the subscriber roams in H- or V-PLMN from the VLR/SGSN/MME identifier, a shared 
VLR/SGSN/MME in a GWCN shall be allocated a separate identifier from each operator sharing that CN node, i.e. a 
shared VLR/SGSN/MME has multiple identifiers. The VLR/SGSN/MME identifier of the user's serving CN operator 
(either the one selected by a supporting UE, or, the one allocated by the network for a non-supporting UE) shall be used 
in signalling with the HSS and the gsmSCF. 

The VPLMN shall ensure that any PLMN ID that is communicated to the HPLMN is that of the selected Core Network 
Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs. An exception to 
this is that the HPLMN operator may specify in the inter-operator roaming/sharing agreement that for non-supporting 
UEs the Common PLMN ID is reported to the HPLMN. 

4.5 Support of Cell Broadcast Services and Warning System 

In shared networks Cell Broadcast and Warning System services are provided via a single common CBC, which 
connects to GERAN/UTRAN as described in TS 23.041 [20] and connects to E-UTRAN as described in TS 23.401 [9]. 
The deployment and configuration of the common CBC is per agreement between the sharing operators. The sharing 
operators need to coordinate the broadcast services between each other, e.g. how to provide Warning System services. 

4.6 Support of Extended Access Barring 

In shared networks, BSC/RNC/eNodeB shall provide independent support for the barring of MSs configured for 
Extended Access Barring (as defined in TS 22.01 1 [23]) for each sharing operator. The BSC/RNC/eNodeB may initiate 
Extended Access Barring for a specific sharing operator when all the SGSNs/MMEs belonging to that sharing operator 
connected to this BSC/RNC/eNodeB request to restrict the load for UEs configured for low access priority, or if 
requested by O&M. Broadcast Extended Access Barring information is specified in TS 44.018 [16] for GERAN, 
TS 25.331 [3] for UTRAN and TS 36.331 [11] for E-UTRAN. 

4.7 Support of service identification for improved radio 
utilization for GERAN 

Service Class Indicator (SCI) for improved radio utilization for GERAN (see TS 23.060 [22]) is supported in shared 
network for A/Gb mode GERAN PS domain. The A/Gb mode GERAN identifies the service class associated with 
downlink user plane packets according to TS 23.060 [22]. When deciding whether to use or discard the SCI 
information, the A/Gb mode GERAN may need to take the identity of the MS's Core Network operator into account. 



5 Functional description 

The new behaviours of network nodes needed in order to describe network sharing are described. 

5.1 UE functions 

A supporting UE selects the core network operator and provides the PLMN-id of this operator to the network for 
routing purposes and to indicate which of the core network operators is selected. 

A supporting GERAN UE provides this indication when establishing a connection with the MSC, and, when sending 
GPRS LLC frames with a non-local TLLI. This includes situations where a supporting UE is DTM capable and in a 
DTM enabled network (e.g. when performing an RA Update after an inter-MSC handover). 

5.2 RNC functions 

Network sharing information, i.e. available core network operators in the shared network, shall be transmitted in 
broadcast system information. 
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If system information relating to NAS is transmitted to a UE in dedicated signalling, the RNC sends information for 
both supporting and non-supporting UEs and the UE shall select the appropriate information to use. 

The RNC shall indicate the selected core network operator to the CN for supporting UEs when transferring initial layer 
3 signalling. The selected CN operator is (i) indicated by the UE in RRC signalling or (ii) known implicitly from an 
already existing signalling connection. For non-supporting UEs, the RNC shall not indicate any selected core network 
operator to the CN. 

In case of relocation to a shared network: 

the source RNC determines a core network operator to be used in the target network, including the selection of 
PLMN(s) to support SRVCC functionality from CS domain to PS, based on available shared networks access 
control information, current PLMN in use. Anchor PLMN, or similar information present in the node, the source 
RNC shall at relocation indicate that selected core network operator to the source core network node as part of 
the TAI/RAI sent in Target ID in the Relocation Required message. The selected target core network operator 
should be the same as the one in use. If the source core network operator is not supported in the target cell the 
RNC selects the target PLMN based on either (i) pre-configured information in the RNC, or (ii) the SNA (Shared 
Network Area) Access Information IE (see TS 25.413 [13]) provided by the SGSN. 

- In order to support SRVCC from CS to PS, the source RNC informs the target RNC/BSC of the Anchor PLMN 
identity. 

The target RNC may need to know whether or not the UE supports UTRAN network sharing. 

NOTE: For PS-to-CS SRVCC, any SRVCC specific PLMN information should be pre-configured in the RNC. 

5.2a eNodeB functions 

Network sharing information, i.e. available core network operators in the shared network, shall be transmitted in 
broadcast system information. 

The eNodeB shall indicate the selected core network operator when transferring initial layer 3 signalling. The eNodeB 
uses the selected core network information (provided by the UE at RRC establishment, or, provided by the MME/source 
eNodeB at S1/X2 handover) to select target cells for future handovers appropriately. 

In case of handover to a shared network: 

the source eNodeB determines a core network operator to be used in the target network based on current PLMN 
in use, or other information present in the eNodeB, the source eNodeB shall at handover indicate that selected 
core network operator to the MME as part of the TAI/RAI sent in the HO required message. The selected target 
core network operator should be the same as the one in use. This is accomplished by not changing the serving 
PLMN if the PLMN in use is supported in the target cell. If the PLMN in use is not supported in the target cell 
the eNB selects the target PLMN based on either (i) pre-configured information in the eNB, or (ii) the Equivalent 
PLMNs Hst (see TS 36.413 [14]) provided by the MME. 

when multiple PLMNs are available for CS domain to support CS Fallback functionality, the source eNodeB 
determines a core network operator to be used in the target GERAN/UTRAN network based on the allocated 
LAI provided by the MME as specified in TS 23.272 [15]. The source eNodeB shall at handover indicate that 
selected core network operator to the MME as part of the Target ID sent in the HO required message. If the 
selected PLMN for CS domain is not supported in the target cell the eNodeB selects the target PLMN based on 
either (i) pre-configured information in the eNodeB, or (ii) the Equivalent PLMNs list (see TS 36.413 [14]) 
provided by the MME. 

when multiple PLMNs are available for CS domain to support SRVCC functionality, the source eNodeB 
determines a core network operator to be used in the target GERAN/UTRAN network. If the currently serving 
PLMN is not supported in the target cell, the eNodeB selects the target PLMN based local configured 
information in the eNodeB along with the information provided by the MME in HRL (see TS 36.413 [14]). The 
HRL provides the currently serving PLMN and equivalent PLMNs together with information about which 
PLMNs are preferred for SRVCC target cell selection. The source eNodeB shall at SRVCC handover indicate 
the selected core network operator to the MME as part of the Target ID sent in the HO required message. 

the target eNodeB uses the selected core network information to select target cells for future handovers 
appropriately. 
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5.2b BSC functions 

Network sharing information, i.e. available core network operators in the shared network, shall be transmitted in 
broadcast system information. 

If system information is transmitted to a supporting UE in dedicated signalling e.g. to support handover to other RATs, 
the BSC shall indicate the PLMN-id of the core network operator towards which the UE already has a signalling 
connection (if a PLMN-id is included in the signalling). If the UE is non-supporting, the BSC shall indicate the common 
PLMN (if a PLMN-id identity is included in the signalling). 

The BSC shall indicate the selected core network operator to the CN for supporting UEs. The selected CN operator is: 

i) indicated by the UE to the BSC as follows: 

for the CS domain, in the Initial L3 message, a supporting UE shall send the PLMN Index that corresponds to 
the position of the chosen PLMN in the broadcast system information, as part of the Initial L3 message. The 
BSC shall then derive the PLMN-id chosen by the UE from the indicated PLMN Index, select the 
corresponding CN operator and inform the MSC of the chosen PLMN-id; 

for the PS domain, when the UE has a non-local TLLI, a supporting UE shall send the PLMN Index that 
corresponds to the position of the chosen PLMN in the broadcast system information, as part of the AS 
signalling. The BSC shall then derive the PLMN-id chosen by the UE from the indicated PLMN Index, select 
the corresponding CN operator and inform the SGSN of the chosen PLMN-id; 



ii) known implicitly from an already existing signalling connection. 
For non-supporting UEs, the BSC shall not indicate any selected core network operator to the CN. 
In the PS domain, when the UE has a local TLLI: 

- for MOCN, the BSC uses the NRI bits from within the TLLI to derive the selected CN operator; 

for GWCN, the SGSN passes the selected CN operator identity with the downlink user data/signalling. 

For handover to a shared network from GERAN: 

the source BSC determines a core network operator to be used in the target network, including the selection of 
PLMN(s) to support SRVCC functionality from CS domain to PS, based on current PLMN in use. Anchor 
PLMN, or other information present in the BSC. The selected target core network operator should be the same as 
the one in use. If the source core network operator is not supported in the target cell the BSC selects the target 
PLMN based on pre-configured information in the BSC. 

the source BSC shall indicate the target core network operator PLMN ID to the source core network node as part 
of the TAI/RAI sent in the Target Cell Identifier IE/Target RNC Identifier IE/Target eNodeB Identifier IE in the 
PS-Handover- Required message (TS 48.018 [24]) and in the LAI sent in the Cell Identifier List IE in the 
Handover Required message (TS 48.008 [25]). 

- In order to support SRVCC for CS to PS, the source BSC informs the target RNC/BSC of the Anchor PLMN 
identity. 

For handover to a GERAN shared network: 

The target BSS needs to know whether or not the UE supports GERAN network sharing. The BSC can 
determine this by using information in XXXXXX. 

Editor's note: Stage 3 design choices will lead to the determination of the ^^^^^|. 

the source RAN determines a core network operator to be used in the target network and indicates the target core 
network operator PLMN ID to the source core network node. The target MSC/SGSN indicates selected core 
network operator to target BSC. 

In all other signalling from the GERAN to the MSC/SGSN, unless specified differently by stage 3 specifications, any 
PLMN ID sent is the Common PLMN ID. In signalling from the Core Network to the GERAN, the BSS shall accept 
signalling that uses any of the PLMN IDs that share the cell. 
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5.3 MSC functions 

When a UE accesses an MSC the first time, i.e. when there is no VLR entry for this UE, the MSC retrieves the IMSI 
from another MSCA'^LR or from the UE. For GWCN, the MSC determines a serving CN operator based on the Selected 
PLMN indicated by the RAN, or, for a non-supporting UE, based on local MSC policy, possibly taking into account the 
"old LAI" information included in the message from the UE. The MSCA'LR shall also store the identity of the serving 
core network operator. 

In case of a MOCN configuration, an MSC may not be able to provide service to the UE. The UE may then have to be 
redirected to a MSC of another core network operator. The MSC/VLR that finally serves the UE assigns a NRI to the 
UE. This will allow the RAN to route any subsequent UE accesses to the serving MSC/VLR. 

The behaviour of the MSC in relation to CS/PS coordination for non-supporting UEs is described in clause 4.2.5. 

In case of GWCN configuration, if the selected PLMN -ID has not been indicated by the RAN (e.g. because the UE is a 
non-supporting UE), the MSC shall indicate the selected PLMN-ID to the BSC/RNC. The BSC/RNC shall store this 
information. 

For supporting UEs, i.e. when a selected core network operator has been indicated to the MSC by the RNC/BSC, the 
MSC indicates the selected core network operator PLMN-id in the LAI signalled to the UE in dedicated signalling. 

For sharing scenarios with both E-UTRAN and GERAN/UTRAN access, where the network also applies idle-mode 
signalling reduction (see TS 23.401 [9]), the contents of the SNA Access Information IE (see TS 25.413 [13]) provided 
by the MSC to the RNC for a specific UE guides the target PLMN selection if the UE's registered PLMN is not 
available in the target cell. The SNA Access Information IE should be configured such that for any target cell there is 
only one PLMN-ID that can be selected for the cell. 

Also, for the above scenario, in the routing areas and tracking areas between which ISR may be activated the 
"equivalent PLMNs" list provided by the SGSN, MSC and MME to a UE (see TS 24.008 [7]) should result in a single 
consistent "equivalent PLMNs" list stored by the UE. The single "equivalent PLMNs" list applies to all the UE's 
registered routing areas, location areas and tracking areas. 

In case of relocation to a GWCN or a MOCN: 

There is no functionality in the source MSC to select a target core network operator or to modify the target core 
network operator selected by the RNC/BSC. 

For handover to a shared UTRAN the source MSC shall forward the selected core network operator chosen by 
the source RNC/BSC to the target MSC, which relays this information unchanged to the target RNC so that the 
appropriate PLMN-id can be signalled to the UE in dedicated system information signalling, as described in 
clause 5.2. 

For handover to a shared GERAN the source MSC shall forward the PLMN-ID selected by the source RAN to 
the target MSC. Target MSC sends information of selected operator to the target BSC. 

Editor's note: How the signalUng of selected operator shall be done from the target BSC to the UE is a Stage 3 
design choice. 

- For SRVCC from E-UTRAN PS to UTRAN/GERAN CS domain, in case of GWCN configuration, the MSC 
selects the target PLMN based on the indication of the selected target PLMN provided by the MME/SGSN in the 
PS-to-CS handover command. The MSC receives the Anchor PLMN from the MME/SGSN and forwai'ds that 
information to the target BSC/RNC. 

For SRVCC from UTRAN/GERAN CS domain to E-UTRAN/HSPA PS, the MSC selects the MME based on selected 
target PLMN provided by the RNC/BSC in handover required message and forwards the selected target PLMN to MME 
in the CS to PS handover request. 

In signalling to the HSS, the MSC shall ensure that any PLMN ID that is sent is the ID of the selected Core Network 
Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs (unless the 
exception to send the Common PLMN ID for a non-supporting UE (see clause 4.4) is in use with that HPLMN). 
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5.4 SGSN functions 

When a UE accesses an SGSN the first time, i.e. when the UE is not yet known by the SGSN the SGSN retrieves the 
IMSI from another SGSN/MME or fi-om the UE. For GWCN, tThe SGSN determines a serving CN operator based on 
the Selected PLMN indicated by the RAN, or, for a non-supporting UE, based on local SGSN policy, possibly taking 
into account the "old RAI" information included with the message from the UE. The SGSN shall store the identity of 
the serving core network operator. 

In case of a MOCN configuration, a SGSN may not able to provide service to the UE. The UE may then have to be 
redirected to a SGSN of another core network operator. The SGSN that finally serves the UE assigns a NRI to the UE. 
This will allow the RAN to route any subsequent UE accesses to the serving SGSN. 

The behaviour of the SGSN in relation to CS/PS coordination for non-supporting UEs is described in clause 4.2.5. 

In case of GWCN configuration, if the selected PLMN -ID has not been indicated by the RNC (e.g. because the UE is a 
non-supporting UE), the SGSN shall indicate the selected PLMN-ID to the RNC. The RNC shall store this information. 

For supporting UEs, i.e. when a selected core network operator has been indicated to the SGSN by the RNC/BSC, the 
SGSN indicates the selected core network operator PLMN-id in the LAI/RAI signalled to the UE in dedicated 
signalling. 

For sharing scenarios with both E-UTRAN and GERAN/UTRAN access, where the network also applies idle-mode 
signalling reduction (see TS 23.401 [9]), the contents of the SNA Access Information IE (see TS 25.413 [13]) provided 
by the SGSN to the RNC for a specific UE guides the target PLMN selection if the UE's registered PLMN is not 
available in the target cell. The SNA Access Information IE should be configured such that for any target cell there is 
only one PLMN-ID that can be selected for the cell. 

Also, for the above scenario, in the routing areas and tracking areas between which ISR may be activated the 
"equivalent PLMNs" list provided by the SGSN, MSC and MME to a UE (see TS 24.008 [7]) should result in a single 
consistent "equivalent PLMNs" list stored by the UE. The single "equivalent PLMNs" list applies to all the UE's 
registered routing areas, location areas and tracking areas. 

At relocation/handover to a GWCN or a MOCN: 

There is no functionality in the source SGSN to select a target core network operator or to modify the target core 
network operator selected by the RNC/BSC. Instead, the source SGSN uses the selected PLMN received from 
the RNC/BSC to determine the target core network operator. The source SGSN shall forward the selected core 
network operator chosen by the source RNC/BSC to the target SGSN/MME. 

For handover to a shared UTRAN the target SGSN indicates the selected core network operator chosen by the 
source RNC/BSC/eNodeB to the target RNC so that the appropriate PLMN-id can be signalled to the UE in 
dedicated system information signalling, as described in clause 5.2. 

- For handover to a shared GERAN the source SGSN/MME shall forward the PLMN-ID selected by the source 
RAN to the target SGSN. Target SGSN sends information of selected operator to the target BSC. 

Editor's note: How the signalling of selected operator shall be done from the target BSC to the UE is a Stage 3 
design choice. 

- For SRVCC from UTRAN PS to UTRAN/GERAN CS domain, the SGSN selects the MSC based on the selected 
target PLMN indicated by the RNC. The SGSN includes the indication of the selected target PLMN in the target 
CGI/RNC ID and Anchor PLMN in the SRVCC PS-to-CS Request sent to the MSC (see TS 29.280 [21]). 

In signalling to the GGSN/S-GW/P-GW and HSS, the SGSN shall ensure that any PLMN ID that is sent is the ID of the 
selected Core Network Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting 
UEs (unless the exception to send the Common PLMN ID for a non-supporting UE (see clause 4.4) is in use with that 
HPLMN). 

5.5 MME functions 

When a UE accesses an MME for the first time, i.e. when the UE is not yet known by the MME, the MME verifies 
whether the UE is permitted to access the selected PLMN. For that purpose the MME retrieves the IMSI from another 
MME/SGSN or from the UE. The MME shall store the identity of the selected core network operator. 
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The MME indicates the selected core network operator PLMN-id to the UE in the GUTI. 

For sharing scenarios with both E-UTRAN and GERAN/UTRAN access, where the network also applies idle-mode 
signalling reduction (see TS 23.401 [9]), the PLMN IDs included in the equivalent PLMN list (as defined in 
TS 24.008 [7]) provided by the MME to the eNB guides the target PLMN selection if the UE's registered PLMN is not 
available in the target cell. The equivalent PLMN list should be configured such that for any target cell there is only one 
PLMN-ID that can be selected for the cell. 

Also, for the above scenario, in the routing areas and tracking areas between which ISR may be activated the 
"equivalent PLMNs" list provided by the SGSN, MSC and MME to a UE (see TS 24.008 [7]) should resuh in a single 
consistent "equivalent PLMNs" list stored by the UE. The single "equivalent PLMNs" list applies to all the UE's 
registered routing areas, location areas and tracking areas. 

For sharing scenarios with both E-UTRAN and GERAN/UTRAN access, when multiple PLMNs are available for CS 
domain to support CS Fallback functionality, the MME provides the allocated LAI including the selected PLMN ID for 
CS domain along with "CS Fallback indicator" to the eNodeB as specified in TS 23.272 [15], to guide the selection of 
the target GERAN/UTRAN network. 

If the operator-configured target network for CS fallback is a shared GERAN, the MME shall take into account the UE 
capability that indicates whether the UE is a GERAN network-sharing supporting UE or a GERAN network-sharing 
non-supporting UE when selecting the PLMN for the CS domain for CS fallback. If the UE is a GERAN network- 
sharing non-supporting UE, a common PLMN-id shall be selected, while if the UE is a GERAN network-sharing 
supporting UE, one of the PLMN-IDs in the Multiple PLMN-ID List of the target shared GERAN shall be selected. 

If the RAT preference for the UE is GERAN and the allocated LAI belongs to a shared GERAN, the list of PLMN IDs 
included in the serving PLMN and equivalent PLMNs list of the handover restriction list (as defined in TS 36.413 [14]), 
if provided by the MME to the eNB for the target PLMN selection, shall be configured taking into account the UE 
capability. If the UE is a GERAN network-sharing non-supporting UE, the equivalent PLMNs list should be configured 
such that for any target GERAN/UTRAN cell, only PLMN-ID(s) associated with the same CN operator as the one UE 
registered in the CS domain can be selected by the eNB. 

At handover/relocation to a GWCN or a MOCN: 

- The source MME uses the TAI/RAI information supplied by the eNodeB to select the target MME/SGSN. There 
is no additional functionality in the source MME to select a target core network operator or to modify the target 
core network operator selected by the eNodeB. Instead, the source MME uses the selected PLMN received from 
the eNodeB to determine the target core network operator. The source MME shall forward the selected target 
core network operator chosen by the source eNodeB to the target MME/SGSN. 

The target MME indicates the selected target core network operator chosen by the source eNodeB/RNC/BSC to 
the target eNodeB so that the eNodeB can select target cells for future handovers appropriately. Subsequent 
Tracking Area Update signalling is used to update the UE about any change of core network operator. 

- At SRVCC from E-UTRAN PS to UTRAN/GERAN CS domain, the MME selects the MSC based on the 
selected target PLMN indicated by the eNodeB. The MME includes the indication of the selected target PLMN 
in the target CGI/RNC ID and Anchor PLMN in the PS-to-CS Request sent to the MSC (see TS 29.280 [21]). 

In signalling to the S-GW/P-GW and HSS, the MME shall ensure that any PLMN ID that is sent is the ID of the 
selected Core Network Operator. 



Charging and accounting aspects 



To support inter-operator accounting in a shared network, it shall be possible to distinguish the share of usage of the 
shared core network node(s) between the sharing partners. The identity of the serving core network operator (either the 
one selected by a supporting UE, or, the one allocated by the network for a non-supporting UE) shall be included in the 
CDR types as specified in TS 32.250 [5] (CS) and TS 32.251 [6] (GPRS/EPS). 

As specified in clause 4.4, for offline charging, the gsmSCF can use the identifier of the MSC/SGSN to determine the 
serving core network operator. 



£75/ 



3GPP TS 23.251 version 11.4.0 Release 11 



20 



ETSI TS 123 251 V1 1.4.0 (2013-01) 



Example signalling flows 



7.1 



Network selection 



Signalling flows for manual and automatic network selection in a shared network architecture for successful and 
unsuccessful registration attempts are presented. 

7.1 .2 Non-supporting UEs in a GWCN configuration 

This example shows network selection for a non- supporting UE in a shared UTRAN/GERAN network. 



Shared SGSN 7 
shared MSC 



Non-supporting 
UE 



1 . System information 



2. UE cannot decode networl^ sharing 

information in system broadcast 

information. 



3. Networl^ selection 
{Common PLMN is candidate) 



4. LAU/RAU/ ATTACH REQUEST 



4. LAU/RAU/ ATTACH REQUEST 



5. ON node determines wtiettier the 
UE is allowed to attach. 



6. LAU/RAU/ATTACH ACCEPT/REJECT 



Figure 3: Network selection for a non-supporting UE in a shared UTRAN/GERAN network 

1 . The UE reads the broadcast system information in the shared RAN. 

2. A non-supporting UE cannot decode the shared network information in the broadcast system information. The 
common PLMN is the only candidate to be considered together with other PLMNs for network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH REQUEST/ROUTEING AREA UPDATE/LOCATION AREA UPDATE message 
to the network. The signalling from the RAN to the Core Network enables the Core Network to determine that 
the UE did not select a Core Network operator. 

5. The shared SGSN determines whether the UE is allowed to attach. 

6. The shared SGSN sends the appropriate ACCEPT/REJECT message back to the UE. 

7.1 .3 Supporting UEs in a GWCN configuration 

This example shows network selection for a supporting UE in a shared E-UTRAN/UTRAN/GERAN network. 
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information in system broadcast 

information. 



3. Networl^ selection 



4. LAU/RAU/ATTACH/TAU REQUEST 



4 .LAU/RAU/ATTACHn"AU REQUEST 



5. CN node determines whettier the 
UE is allowed to attach. 



6. LAU/RAU/ATTACHTAU ACCEPT/REJECT 



Figure 4: Network selection for a supporting UE in a shiared E-UTRAN/UTRAN/GERAN networl< 

1 . The UE reads the broadcast system information in the shared RAN. 

2. A supporting UE decodes the shared network information and suppUes the available core network operator 
PLMN-ids as candidates to the PLMN selection procedure. Only PLMNs in the Multiple PLMN ID List are 
candidates for network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH/ROUTEING AREA UPDATE/TRACKING AREA UPDATE/LOCATION AREA 
UPDATE REQUEST message to the network indicating, to the RAN, the chosen core network operator. The 
RAN converts the core network 'indicator' into the actual selected PLMN identity and sends this with the 
ATTACH/ROUTEING AREA UPDATE/TRACKING AREA UPDATE/LOCATION AREA UPDATE 
REQUEST to the core network. 

5. The shared SGSN determines whether the UE is allowed to attach. 

6. The shared SGSN sends the appropriate ACCEPT/REJECT message back to the UE. 



7.1 .4 Non-supporting UEs in a MOCN configuration 



7.1.4.1 



UTRAN based MOCN configuration 



An example of an information flow for redirection in UTRAN is shown below. 

In this example an attach request from a non-supporting UE is directed to three different CN operators. The first rejects 
since it has no roaming agreement with the subscribers Home PLMN. The second rejects because of a roaming 
restriction found in HLR. The third CN operator accepts and completes the attach request. The different "MSC/SGSNs" 
in the example below shall be seen as different CN operators. One specific CN operator may also have several pooled 
MSCs/SGSNs connected to the RNC if lu-flex is used. 
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Figure 5: Information flow for redirection in UTRAN 

1) The RRC connection is established. 

2) RNC receives an Initial Direct Transfer from an UE. The RNC is configured to work in a Shared RAN MOCN, 
and therefore it forwards the NAS message in an Initial UE message with an additional redirect attempt flag set. 
The flag indicates that the MSC/SGSN shall respond to the attach request with a Reroute Command or Reroute 
Complete IE in the Direct Transfer message. Selection of CN node is based on NRI (valid or invalid) if present 
in IDNNS or by random selection. 

A redirect attempt flag could also simply be the fact that the Initial UE message does not include any selected 
PLMN-ID, which a supporting UE would include. Redirect is never done for supporting UEs. 

3) The MSC/SGSN receives the Initial UE with the redirect attempt flag set. It then knows it shall answer with a 
Reroute Command or Reroute Complete IE in the Direct Transfer message. 

4) The MSC/SGSN needs the IMSI of the UE. It is retrieved either from old MSC / old SGSN or from the UE as in 
this example. By comparing the IMSI with the roaming agreements of the CN operator, the MSC/SGSN 
discovers that roaming is not allowed or that roaming is allowed but CS/PS coordination required. Attach 
procedure is aborted. 

5) A message is sent back to the RNC with two NAS messages, the attach reject message and the original attach 
request message received from the UE (alternatively the original NAS message may be stored in the RNC). The 
IMSI is also included in the message, plus a reject cause code to the RNC. The Reroute Command IE is in the 
Direct Transfer message. 

The signalling connection between RNC and MSC/SGSN A is released. The RNC selects a MSC/SGSN in the 
next step. The already tried MSC/SGSNs is stored in the RNC during the redirect procedure so that the same 
node is not selected twice. 
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6) The RNC sends a new Initial UE to the next selected MSC/SGSN with the original NAS attach request message 
(in case of CS/PS coordination the Initial UE may also be sent back to the first MSC/SGSN depending on the 
outcome of the coordination). Redirect attempt flag is set and IMSI shall also be included to avoid a second 
IMSI retrieval from UE or old MSC/SGSN and to indicate that PS/CS domain coordination has been done in 
RNC (if enabled in RNC). The MSC/SGSN receiving the message starts its attach procedure. 

7) MSC/SGSN B does in general support roaming for the HPLMN of the IMSI and hence authentication is done 
and RAN ciphering is established. 

8) MSC/SGSN B updates the HLR and receives subscriber data from HLR. 

9) The subscription data do not allow roaming (e.g. regional or 3G). MSC/SGSN B sends a Reroute Command 
message including the attach reject message, a reject cause code, the original attach request message 
(alternatively stored in the RNC), and the N(SD) (for MSC only). IMSI is included in Reroute Command 
message only if it was not included in the Initial UE received by the MSC/SGSN. 

The signalling connection between the RNC and the MSC/SGSN B is released. The RNC then selects a new 
MSC/SGSN as in step 5. 

10) The MSC/SGSN C receives an Initial UE (with the original NAS attach request message) with the redirect 
attempt flag is set, an IMSI, and N(SD) (if MSC). The MSC/SGSN C starts the attach procedure and uses 
provided information (IMSI and N(SD)). 

1 1) MSC/SGSN C does in general support roaming for the HPLMN of the IMSI and hence authentication is done 
and RAN ciphering is established. 

12)MSC/SGSN C updates the HLR and receives subscriber data from HLR. Subscriber data allows roaming, and 
the MSC/SGSN C completes the attach procedure. This includes the assignment of a new TMSI/P-TMSI with an 
NRI that can be used by RNC to route subsequent signalling between UE and correct MSC/SGSN (lu-flex 
functionality). The Update Location sent to HLR also triggers a Cancel Location sent to the MSC/SGSN B. 

13) A Reroute Complete IE in the Direct Transfer message with the NAS Attach accept message is sent to RNC. By 
this, the RNC knows that the redirect is finished and can both forward the NAS message to the UE and clean up 
any stored redirect data. 

14) The Attach Accept is forwarded to the UE. The UE stores the TMSI/P-TMSI with the lu-flex NRI to be used for 
future signalling, even after power off. This is existing functionality. 

15)UE responds with an Attach Complete message. 

If the RNC finds no more MSC/SGSN to redirect to after receiving a Reroute Command message, e.g. step 5 or step 9, 
it compares the cause code with cause codes from other Reroute Command messages it has earlier received for this UE. 
A cause code ranking is done and the "softest" cause code is chosen and the corresponding saved NAS attach reject 
message is returned to the UE. 

Each CN node that receives an Initial UE, shall run its own authentication procedure. This may in some rare situations 
cause the UE to be authenticated more than once, however the trust-model used is that one CN operator shall not trust 
an authentication done by another CN operator. This will of course not be an optimal usage of radio resources, but 
given the rare occurrence of this, the increased signalling should not be of any significance. 

During the redirect procedure the RNC keeps a timer, which corresponds to the UE timer of releasing the RR 
connection (20 seconds). If the RNC when receiving a Reroute Command message finds that there is not sufficient time 
for another redirect, further redirect attempts are stopped (for this attach request message). The UE will repeat its attach 
request four times (each time waiting 15 seconds before it re-establishes the RR connection for another try). 

7.1 .4.2 GERAN based MOCN configuration 

An example of an information flow for redirection in GERAN is shown below. 

In this example an attach request from a non-supporting UE is directed to two different CN operators. The first CN 
operator rejects since it has no roaming agreement with the subscribers Home PLMN. The second CN operator accepts 
and completes the attach request. The different "MSC/SGSNs" in the example below shall be seen as different CN 
operators. One specific CN operator may also have several pooled MSCs/SGSNs connected to the BSC if A/Gb-Flex is 
used. 
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Figure 6: Information flow for redirection in GERAN (CS domain) 

1) The RRC connection is established. 

2) BSC receives the Layer 3 message from an UE. The BSC is configured to work in a Shared RAN MOCN, and 
therefore it forwards the message in a Complete Layer 3 Information message with an additional redirect attempt 
flag set. The flag indicates that the MSC shall respond to the attach request with a Reroute Command message to 
inform the BSC that a redirection to another CN has to be performed. 

The selection of CN node is based on NRI (valid or invalid) or by random selection. The same mechanism as 
defined for A-Flex in TS 23.236 [8] is used. 

3) The MSC receives the Complete Layer 3 Information message with the redirect attempt flag set. It then knows it 
may have to provide the BSC with a Reroute Command message. 

4) The MSC needs the IMSI of the UE. It is retrieved either from old MSC or from the UE as in this example. By 
comparing the IMSI with the roaming agreements of the CN operator, the MSC A discovers that roaming is not 
allowed or that roaming is allowed but CS/PS coordination required. Attach procedure is aborted. 

5) A Reroute Command message is sent back to the BSC with the attach reject message and the original attach 
request message received from the UE. The IMSI is also included in the message, plus a reject cause code to the 
BSC. 

The signalling connection between BSC and MSC A is released. The BSC selects a MSC B in the next step. The 
already tried MSC A is stored in the BSC during the redirect procedure so that the same node is not selected 
twice. 
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6) The BSC sends a new Complete Layer 3 Information to the next selected MSC B with the original attach request 
message (in case of CS/PS coordination the Complete Layer 3 Information may also be sent back to the first 
MSC depending on the outcome of the coordination). Redirect attempt flag is set and IMSI shall also be included 
to avoid a second IMSI retrieval from UE or old MSC and to indicate that PS/CS domain coordination has been 
done in BSC (if enabled in BSC). The MSC B receiving the message starts its attach procedure. 

7) MSC B does in general support roaming for the HPLMN of the IMSI and hence authentication is done and RAN 
ciphering is established. 

8) MSC B updates the HLR and receives subscriber data from HLR. Subscriber data allows roaming, and the MSC 
B completes the attach procedure. This includes the assignment of a new TMSI with an NRI that can be used by 
BSC to route subsequent signalling between UE and correct MSC (A-Flex functionality). 

9) The Attach Accept is forwarded to the UE. The UE stores the TMSI with the A-Flex NRI to be used for future 
signalling, even after power off. This is existing functionality. 

10) UE responds with an Attach Complete message (TMSI (re-)allocation if not already made in Attach accept). 

11) A Reroute Complete message is sent to BSC. The BSC knows that the redirect is completed and clean up any 
stored redirect data. 

If the BSC finds no more MSC to redirect to after receiving a Reroute Command message, it compares the cause code 
with cause codes from other Reroute Command messages it has earlier received for this UE. A cause code ranking is 
done and the "softest" cause code is chosen and the corresponding saved attach reject message is returned to the UE. 

Each CN node that receives a Complete Layer 3 Information shall run its own authentication procedure. This may in 
some rare situations cause the UE to be authenticated more than once, however the trust-model used is that one CN 
operator shall not trust an authentication done by another CN operator. This will of course not be an optimal usage of 
radio resources, but given the rare occurrence of this, the increased signalling should not be of any significance. 

During the redirect procedure the BSC keeps a timer, which corresponds to the UE timer of releasing the RR connection 
(20 seconds). If the BSC when receiving a Reroute Command message finds that there is not sufficient time for another 
redirect, further redirect attempts are stopped (for this attach request message). The UE will repeat its attach request 
four times (each time waiting 15 seconds before it re-establishes the RR connection for another try). 
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Figure 7: Information flow for redirection in GERAN (PS domain) 

1) The TBF is established. 

2, 2a) BSC receives the LLC frame with foreign [or random] TLLI =X. 

The BSC is configured to work in a Shared RAN MOCN, and therefore it forwards the message in a BSSGP UL- 
UNITDATA message with an additional redirect attempt flag set. The flag indicates that the SGSN shall respond 
to the attach request with a BSSGP DL-UNITDATA message providing when relevant a redirection indication 
flag set to inform the BSC that a redirection to another CN has to be performed. 

The selection of CN node is based on NRI (valid or invalid) or by random selection. The same mechanism as 
defined for Gb-Flex in TS 23.236 [8] is used. 

3) The SGSN receives the BSSGP UL-UNITDATA message with the redirect attempt flag set. It then knows it may 
have to provide the BSC with a redirection indication flag set or a redirection completed flag set. 

4) The SGSN needs the IMSI of the UE. It is retrieved either from old SGSN or from the UE as in this example. By 
comparing the IMSI with the roaming agreements of the CN operator, the SGSN A discovers that roaming is not 
allowed or that roaming is allowed but CS/PS coordination required. Attach procedure is aborted. 

5a) A BSSGP DL-UNITDATA message is sent back to the BSC with a redirection indication flag set containing the 
reject cause, the attach reject message and the original attach request message received from the UE. The V(U) 
used for LLC-PDU setting (refer to TS 44.064 [19]) is included in the message. The IMSI is also included in the 

message. 

The BSC selects a SGSN B in the next step. The already tried SGSN A is stored in the BSC during the redirect 
procedure so that the same node is not selected twice. 

5b) The BSC makes a short-lived binding between the TLLI =X and SGSN ID so that it points to SGSN B. 
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6) The BSC sends a new BSSGP UL-UNITDATA to the next selected SGSN B with the original attach request 
message (in case of CS/PS coordination the BSSGP UL-UNITDATA may also be sent back to the first SGSN 
depending on the outcome of the coordination). Redirect attempt flag is set and IMSI shall be included to avoid a 
second IMSI retrieval from UE or old SGSN and to indicate that PS/CS domain coordination has been done in 
BSC (if enabled in BSC). The V(U) shall also be included in the message. The SGSN B receiving the message 
starts its attach procedure. 

7) SGSN B does in general support roaming for the HPLMN of the IMSI and hence authentication is done and 
RAN ciphering is established. The value of V(U) in SGSN-B shall be set according to the received value from 
BSC. 

UpUnk LLC frames shall be routed to SGSN B despite the NRI of the TLLI=X pointing to SGSN A. 

8) SGSN B updates the HLR and receives subscriber data from HLR. Subscriber data allows roaming, and the 
SGSN B completes the attach procedure. This includes the assignment of a new P-TMSI with an NRI that can be 
used by BSC to route subsequent signalling between UE and correct SGSN (Gb-Flex functionality). 

9) A BSSGP DL-UNITDATA Attach accept message is sent to BSC with the redirection completed flag set . The 
BSC knows that the redirect is finished and can both forward the Attach Accept message to the UE and clean up 
any stored redirect data. 

SGSN B is allowed to reset the XID parameter only after the attach request is accepted. 

10) The Attach Accept is forwarded to the UE. The UE stores the P-TMSI with the Gb-Flex NRI to be used for 
future signalling, even after power off. This is existing functionality. 

1 1)UE responds with an Attach Complete message (P-TMSI (re-)allocation if not already made in Attach Accept). 
The Attach Complete uses new TLLI. After this, the BSS releases the binding between TLLI=X and SGSN B. 

If the BSC finds no more SGSN to redirect to after receiving a BSSGP DL-UNITDATA message with the redirection 
indication flag set, it compares the cause code with cause codes from other BSSGP DL-UNITDATA messages it has 
earlier received for this UE. A cause code ranking is done and the "softest" cause code is chosen and the corresponding 
saved attach reject message is returned to the UE. 

Each CN node that receives a BSSGP UL-UNITDATA, shall run its own authentication procedure. This may in some 
rare situations cause the UE to be authenticated more than once, however the trust-model used is that one CN operator 
shall not trust an authentication done by another CN operator. This will of course not be an optimal usage of radio 
resources, but given the rare occurrence of this, the increased signalling should not be of any significance. 

During the redirect procedure the BSC keeps a timer, which corresponds to the UE timer of releasing the RR connection 
(20 seconds). If the BSC when receiving a BSSGP DL-UNITDATA message with the redirection indication flag set 
finds that there is not sufficient time for another redirect, further redirect attempts are stopped (for this attach request 
message). The UE will repeat its attach request four times (each time waiting 15 seconds before it re-establishes the RR 
connection for another try). 

7.1 .5 Supporting UEs in a MOCN configuration 
7.1 .5.1 UTRAN based MOCN configuration 

Supporting UEs can make use of the additional information in the broadcast system information. The UTRAN 
signalling flow is shown in the figure below. 



£75/ 



3GPP TS 23.251 version 11.4.0 Release 11 



28 



ETSI TS 123 251 V1 1.4.0 (2013-01) 



SGSN 
Operator A 



SGSN 
Operator B 



L ATTACH REQUEST 



5. CN node determines 
whether the UE is allowed 

to attach. 



Supporting UE 



1 . System information 



RNC uses information in header to 

route the ATTACH REQUEST to the 

chosen core network operator 



6. ATTACH ACCEPT/REJECT 



2. UE decodes network sharing 

information in system broadcast 

information. 



3. Network selection 



Figure 8: Network selection by a supporting UE in a UTRAN lUIOCN 

1 . The UE reads the broadcast system information in the shared RAN. 

2. A supporting UE decodes the shared network information and supplies the available core network operator 
PLMN-ids as candidates to the PLMN selection procedure. Only PLMNs in the Multiple PLMN ID List are 
candidates for network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH REQUEST message to the network. It also indicates to the RNC the chosen core 
network operator. The RNC uses the routing information to determine which core network operator the message 
should be routed to and the ATTACH REQUEST message is sent to the core network operator chosen by the 
UE. 

5. The core network determines whether the UE is allowed to attach to the network. 

6. The shared core network node sends the appropriate ACCEPT/REJECT message back to the UE. In case of an 
ATTACH ACCEPT message, the core network assigns the UE an appropriate TMSI/P-TMSI so that this identity 
can be used for any further rerouting of messages by the RNC. 
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7.1.5.2 



GERAN based MOCN configuration 



Supporting UEs can make use of the additional information in the broadcast system information. The GERAN 
signalling flow is shown in the figure below. 
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Figure 9: Network selection by a supporting UE in a GERAN MOCN 

1 . The UE reads the broadcast system information in the shared RAN. 

2. A supporting UE decodes the shared network information and supplies the available core network operator 
PLMN-ids as candidates to the PLMN selection procedure. Only PLMNs in the Multiple PLMN ID List are 
candidates for network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH REQUEST message to the network. It also indicates to the BSC the chosen core 
network operator (via Initial L3 message for CS domain, via AS signalling for the PS domain). The BSC uses the 
routing information to determine which core network operator the message should be routed to and the 
ATTACH REQUEST message is sent to the core network operator chosen by the UE together with the chosen 
PLMN-id. 

5. The core network determines whether the UE is allowed to attach to the network. 

6. The core network node sends the appropriate ACCEPT/REJECT message back to the UE. In case of an 
ATTACH ACCEPT message, the core network assigns the UE an appropriate TMSI/P-TMSI so that this identity 
can be used for any further rerouting of messages by the BSC. 
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Annex A (informative): 

Network Resource Indicator (NRI) allocation examples 

This annex contains examples for NRI co-ordination for non-supporting UEs in shared networks. 

A.1 NRI in shared UTRAN/GERAN networks 

The Network Resource Identifier (NRI) is specified in Rel-5 for Intra Domain Connection of RAN Nodes to Multiple 
CN nodes (see TS 23.236 [8]). NRI is part of the temporary identity TMSI (CS domain) or P-TMSI (PS domain), which 
is assigned by the serving CN node to the MS. This clause describes NRI usage in MOCN. 

Within the shared network NRIs has to be coordinated between the operators at least due to following reasons: 

to avoid redirection or CS/PS coordination when the non- supporting UE performs LA/RA update. 

to achieve that correct UE answers to paging (TMSI/P-TMSI shall be unique within shared network). 

to achieve that a non-supporting UE in visited PLMN will not change network due LA/RA update or 
Detach/ Attach function. 

to achieve that non-supporting UE in visited PLMN becomes CS/PS coordinated when the UE moves within 
shared network. 

NRI coordination is also required between the shared network and the dedicated networks of the sharing partners: 

to achieve that non-supporting UE in visited PLMN remain registered in the same operators network when the 
UE moves from dedicated network to a shared network. 

to achieve that non-supporting UE in visited PLMN remains CS/PS coordinated when the UE moves from 
dedicated network to a shared network. 

to avoid redirection or CS/PS coordination when the non-supporting UE in home PLMN performs LA/RA 
update from dedicated network to a shared network. 

NRI and MMEC coordination is also required between shared UTRAN or GERAN and E-UTRANs of the sharing 
partners: 

to achieve that non-supporting UE in visited PLMN remain registered in the same operators network when the 
UE moves from dedicated network to a shared network. 

to achieve that non-supporting UE in visited PLMN becomes CS/PS coordinated when the UE moves from 
EUTRAN to a shared UTRAN or GERAN network. 

to avoid redirection or CS/PS coordination when the non-supporting UE in home PLMN performs LA/RA 
update from dedicated network to a shared network. 

CS/PS coordination is achieved by allocating to the UE, an NRI for the CS domain and an NRI for the PS domain that 
indicate the same operator in the shared network. 

At LA/RA update the RNC/BSC routes the NAS message to the operator that is defined by NRI, even if NRI is created 
in a PLMN different from Common PLMN. 

Only when a CN node receives a registration from a subscriber with a non-supporting UE having a P-TMSI/TMSI not 
belonging to the shared and non-shared networks of the operator , it returns a Reroute Command message to the 
RNC/BSC (according to clause 7.L4 "Non- supporting UEs in a MOCN configuration") with an indication that it is for 
coordination purposes. 

In figure A. 1 below operators A, B and C have both shared and dedicated networks, operator D has only dedicated 
network and operator E only shared network. 
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Figure A.I : Shared and Dedicated network example 

In the above, one or more of the operators in the shared network may deploy lu-Flex or A/Gb-Flex between that shared 
radio access network and their core networks. Additionally, operators may deploy lu-Flex or A/Gb-Flex within their 
dedicated core networks. For non-supporting UEs, NRJ coordination is needed not only within the shared network, but 
also between the shared network and the dedicated networks. 



A.2 Alternatives for NRI split in UTRAN and GERAN 

Sharing operators need to coordinate the used NRI, following alternatives are considered: 

1) even split of NRI space, 1...3 most significant bits of NRI is used to identify the CN operator. 

2) individual NRI values used to identify the CN operator. 
Alternative 1; even split of NRI space 
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A calculation for the possible number of subscribers in this scenario is: 

With max 4 sharing CN operators, two most significant bits of NRI is required to identify the CN operator. 

3 bits are used for the restart counter. 

5 bits of NRI allows 32 independent NRI values for each CN operator. 

- This leaves 20 bits for every MSC that is 1 M non-purged TMSI. 

The following aspects need to be considered for this solution: 

If more bits are needed for the restart counter or CN operator ID, each additional bit reduces the available TMSI 
space half. 

The basic configuration allows 32 M TMSI values for each CN operator, a lot of TMSI values are wasted if 
some sharing partners have substantially less subscribers than others. 

It may not be feasible in large networks that use lu-Flex or A/Gb-Flex for load balancing (see Annex A, network 
configuration examples in TS 23.236 [8]). 

The number of NRI bits used for CN operator ID may need to be fixed in the initial planning. Otherwise 
configuration of all existing nodes must be changed when new partners join the shared network. 
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Alternative 2; individual NRI values used to identify the CN operator 

This could be considered in the case where a network is shared between one big and many small CN operators. 
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The biggest CN operator who needs more pool areas and TMSI space takes NRI values 32. . .63, [Ixxxxx], this 
means 32M TMSI values when 4 bit is used for restart counter. 

Rest of shared NRI space is allocated to other CN operators in blocks of 4M TMSI values like NRI = 28 - 3 1 
[0111 xx] ,24-27 [Oil Oxx] .... - 3 [OOOxx] . Initially gaps can be left between allocated NRI range that can be 
used for expansion. 

Following aspects need to be considered for this solution: 

If more bits are needed for the restart counter or NRI, each additional bit reduces the available TMSI space half. 

The initial planning of NRI length should take into account the pool area configurations of all sharing operators. 

TMSI per LA: 

Taking the example configurations mentioned above but changing the TMSI allocation per LA would result in an 
increase of the addressing space, then the same TMSI value can be used multiple times in the same VLR. More 
considerations with this TMSI per LA approach can be found in TS 23.236 [8]. 

A.3 NRI and CS/PS coordination in GWCN 

For GWCN, the SGSN and MSC determines a serving CN operator at attach for a non-supporting UE based on local 
SGSN/MSC policy. The local policy configuration is same in SGSN and MSC, such that determined CN operator 
outcome (deterministic outcome) is the same in CS and PS domain. 

When source network determines target CN operator in handover and CS fallback, the NRI and MMEC coordination is 
required as for MOCN (see clause A.l) within the shared network and between the shared network and the dedicated 
networks of the sharing partners: 

to achieve that a non-supporting UE in visited PLMN will not change network due LA/RA update; 

to achieve that non-supporting UE in visited PLMN becomes CS/PS coordinated. 

At location update and routing area update the CN nodes determines serving CN operator based on NRI. 

CS/PS coordination is achieved by allocating to the UE, an NRI for the CS domain and an NRI for the PS domain that 
indicate the same operator in the shared network. 
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Annex B (normative): 

Interaction with other network capabilities 

B.1 General 

The provision of services and service capabilities in a network should not be restricted by the existence of network 
sharing. Therefore, all new features (or enhancements to existing features) should be specified to work in network 
sharing environments. If it is not possible to specify complete support for Network Sharing (i.e. PLMNs in a Shared 
Network has the same features/capabilities and the same operational situation as a stand alone PLMN) then such 
deviations are documented in this Annex. 



B.2 Support for RAN sharing for CSG and hybrid cells 

A cell with closed/hybrid access can only broadcast one CSG ID but may broadcast several PLMN IDs. If a cell with 
closed/hybrid access broadcasts several PLMNs (see clauses 5.2 and 5.2a) for a UE supporting shared network or a non- 
supporting UE that performs the PLMN selection (see clause 4.2.3.2), it is the operator responsibility to coordinate the 
CSG IDs between the operators' PLMNs. For further details on Closed Subscriber Group (CSG) and closed/hybrid 
access, see TS 36.300 [10] and TS 25.467 [17]. 
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